Roles for Agent Technology in Knowledge Management: Examples fromApplications in Aerospace and Medicine

This paper describes some of the roles of agents in knowledge management based our experience in aerospace and medicine. After an overview of agent technology and the KAoS agent architecture and applications, we show how agents can help address problems of 1) managing dynamic loosely-coupled information sources, 2) how to provide a unifying framework for distributed heterogeneous components, and 3) coordinating interaction at the knowledge-level. 1. The Place of Agents in Knowledge Management and Knowledge Sharing Predicting the future is difficult business. A few short years ago, it seemed obvious to most of the knowledgebased community that an era of widespread knowledge sharing (Neches, Fikes, Finin, Gruber, Patil, Senator, & Swartout, 1991) was about to begin (Bradshaw, Ford, Adams-Webber, & Boose, 1993). Libraries of ontologies crafted by groups with common interests in particular knowledge domains would enable the development of computational environments in which explicitly represented knowledge would serve as a means of communication among people and their (Bradshaw, Holm, Boose, Skuce, & Lethbridge, 1992; Gruber, 1991. How closely has reality approached our expectations? A few observations are instructive: Observation 1. Knowledge sharing as we originally envisioned it has not occurred on a widespread basis. This is not meant to imply that efforts to promote knowledge sharing and reusability through methods like the use of ontologies have stopped—indeed, if the proceedings of the 1996 Banff Knowledge Acquisition Workshop are any indication, interest in the topic is healthier than ever. What we are saying is simply that knowledge sharing efforts have not yet had the widespread impact in applications we have been hoping for. Instead, the unforeseen explosion of Web technology and usage has led to a different form of knowledge sharing altogether. No longer does the bottleneck of knowledge acquisition command our attention as it once did—instead, we are scrambling to find ways to impose structure and meaning on the virtual firehose of mostly document-based “knowledge” that is available to us freely on the Web. The transition of Guha from a co-lead of the most ambitious hand-crafted ontology ever (Guha & Lenat, 1990) to a developer of methods for automatically structuring and navigating information on the Web (Guha, 1996) is a striking symbol of this very trend. Observation 2. The standard architecture for intelligent systems has been turned inside out. Instead of one or a few large sophisticated systems that communicate in simple ways, there is an increasing demand for large groups of simple offthe-shelf components whose actions are coordinated in sophisticated ways (Orfali, Harkey, & Edwards, 1996. That the components will be heterogeneous, distributed, and highly interactive is now taken for granted, along with the expectation that the unifying framework in which they operate must not only successfully coordinate their use today but also allow for the introduction of new or replacement components and technologies in the future (Bradshaw, in preparation). Observation 3. Progress in standards for component-level interoperability has not obviated the requirement for knowledge-level interoperability. The wide adoption of distributed object (CORBA, DCOM, Java), data (HTML, QuickTime), communication (HTTP, TCP/IP, IIOP), and component integration standards (Netscape ONE, OpenDoc, ActiveX, Java Beans) has provided the means for us to package our technologies as interoperable components. However, as has been frequently argued (Bradshaw, 1996b; Gaines & Shaw, 1996; Genesereth, 1996; Gennari, Stein, & Musen, 1996; Kremer, 1996), there is still much work to be done on “knowledge-level” methodologies and standards that can ensure that the operational semantics of these components are explicitly represented. Software agents have been proposed as one way to help resolve the problems raised by these three observations. While it is true that point solutions not requiring agents could be devised to address many if not all of the issues raised by above, the aggregate advantage of agent technology is that it can address all of them at (Harrison, Chess, & Kershenbaum, 1995. Software agents can be generally defined as entities that function continuously and autonomously in a particular environment that is often inhabited by other agents and processes. Ideally, agents learn from their experiences, communicate and cooperate with people and with other agents, and, as required, move from place to place within private networks and on the public Internet. Because the widespread use of agents is a fairly recent phenomenon, there is often confusion expressed about whether some particular software component is “really” an agent or “really” just a program (Franklin & Graesser, 1996). To some degree this is a debate that can never be fully resolved because agenthood is typically a matter of degree rather than kind (Bradshaw, 1996a). For example, while it is true that agents can certainly be implemented in Java, not all Java programs are equally “agent-like”: • Mobile agents tend to move around according to their own agenda (“multi-hop”) whereas most garden variety applets are obtained from client pull (“single hop”). This aspect of relative autonomy is perhaps the most distinguishing characteristic of agents. • Agents are capable of preserving their own state as they are activated, deactivated, and travel from machine to machine, whereas it is typical for applets to start up fresh each time. This gives agents the possibility of adapting and accumulating knowledge and experience over long periods of time. What kind of roles do agents typically perform? At the user interface, agents can work in conjunction with compound document frameworks and document management tools to select the right data, assemble the needed components, and present the information in the most appropriate way for a specific user and situation (figure 1). Behind the scenes, agents can take advantage of distributed object management, database, workflow, messaging, transaction, searching, indexing, and networking capabilities to discover, link, and securely access the appropriate data and services. In this paper we describe examples of some of the roles that agent technology can play in knowledge management. First we give an overview of the KAoS agent architecture and some of the aerospace and medical applications to which it is being applied (section 2). Then we show how agents can address problems related to the three observations above by 1) managing dynamic looselycoupled information sources (section 3), 2) providing a unifying framework for distributed heterogeneous components (section 4), and 3) coordinating interaction at the knowledge-level (section 5). Integrated interface to knowledge media Agent as personal assistant Agents as intelligent interface managers Agents behind the scenes Interapplication communication Agent-to-agent communication Figure 1. An agent-enabled system architecture. 2. KAoS Overview and Applications Overview. In 1992, we began a collaboration with the Seattle University (SU) Software Engineering program to develop the first version of the KAoS (Knowledgeable Agent-oriented System) generic agent architecture. We are currently enhancing two main versions: one written in portable Java code and the other written in C++ to take advantage of Microsoft’s ActiveX and DCOM technologies. KAoS is described in more detail (Bradshaw, Dutfield, Benoit, & Woolley, 1996). Basic characteristics of KAoS agents include a consistent structure providing mechanisms allowing the management of knowledge, commitments, choices, and capabilities. Agent dynamics are managed through a cycle that includes the equivalent of agent birth, life, cryogenic state, and death. Each agent contains a generic agent instance, which implements as a minimum the basic infrastructure for agent communication. Specific extensions and capabilities can be added to the basic structure and protocols through standard object-oriented mechanisms. Mediation agents provide an interface between a KAoS agent environment and external entities, resources, or agent frameworks. Proxy agents extend the scope of the agent-to-agent protocol beyond a particular domain. The Domain Manager1 controls the entry and exit of agents in a domain according to policies set by the domain administrator. The Matchmaker2 can access information about the location of the generic agent instance for any agent that has advertised its services. The Transport Agent3 facilitates teleportation (transfer of an entire agent from one agent domain to another) and telesthesia (transfer of the agent’s extension to another host). Messages are exchanged between agents in the context of conversations. Verbs name the type of illocutionary act (e.g., request, promise) represented by a message. Unlike most agent communication architectures, KAoS explicitly takes into account not only the individual message, but also the various sequences of messages in which it may occur. Shared knowledge about message sequencing conventions (conversation policies) enables agents to coordinate frequently recurring interactions of a routine nature simply and predictably. Suites provide convenient groupings of conversation policies that support a set of related services (e.g., the Matchmaker suite). A starter set of suites is provided in the architecture but can be extended or replaced as required. Our experience with the current KAoS architecture has shown it to be a powerful and flexible basis for diverse types of agent-oriented systems. The strength of the architecture derives from several sources: • it is built on a foundation of distributed object technology and is optimized to work with component integration architectures such as OpenDoc, ActiveX, and Java and with distributed object services such as those provided by CORBA and DCOM; • it supports structured conversations which: • preserve and make use of the context of agent communication at a higher level than single messages, • allow differential handling of messages depending on the particular conversation policy and the place in the conversation where the message occurs, • permit built-in generic handlers for common negotiation processes such as countering; • it allows the language of inter-agent communication to be extended in a principled 1 Also called the CIA (Central Intelligence Agent) 2 Also called the KGB Agent (KAoS Generic Broker). 3 Also called the KOA Agent, after the popular US campground chain that provides service hookups for the mobile homes of travelers. manner, allowing verbs and conversation policies to be straightforwardly reused, adapted, or specialized for new situations; • it groups related sets of conversation policies into suites supporting a coherent set services; • it provides facilities for service names (“yellow pages”), which are registered by agents offering services; • it provides facilities for agent names (“white pages”), which uniquely identify an agent as long as it persists; • it is appropriate for a wide variety of domains and implementation approaches and is platformand